Simple Requestの基準の理由

なぜSimple Requestが、このような基準なのか

SOPとCORSの歴史的経緯を知らないと理解しづらいmrsekut.icon

結論

SOPが適用されないものに相当するものがSimple Requestになっている

もっと雑に言えば、「<form>で送信できるもの」がSimple Requestの基準になっている

時代の流れとしては、

SOPがない→SOPが入る→CORSが入る

という順序を踏んでいる

ここで、SOPが追加された直後のことを考えると

SOPが適用されないものは、SOPの導入に関わらずセキュリティのリスクが存在することになる

例えば、formの送信はSOPが適用されない

ということは、formの送信に関しては、server側でセキュリティ対策が施されているべきである

また、SOPが入ったということは、

そもそもcross-originからPUTやDELETEが飛んでくることはない、となる

だから、ここに関してセキュリティ対策をしなくても安全である

この状態で、CORSが追加される

すると、POSTだけでなく、PUTやDELETEもcross originから飛んできうることになる

POSTなどに対しては、既にセキュリティ対策が為されているが、

PUTやDELETEに対しては対策されていない

つまり、ここで線引きが必要になるmrsekut.icon

もし、この状況下で(preflight requestのない)CORSが追加されると、

Cross OriginからPUTやDELETEが飛んできて、CSRF攻撃を受けてしまう

responseは関係なく、requestでCSRF攻撃は完了できるmrsekut.icon

これは非常にまずく、server側が新たに対策を実装する必要が出てくる

そこで、serverに送る前に「server側は許可してくれますか？」を確認するためにPreflight Requestを送ることにした

全部Preflight Request必須にすれば良くない？とも考えられる

ただし、そうするとPreflight Request分のRTTが1回分増える

不要なRTTは避けたいし、そもそもセキュリティ対策されているはず(前提)

だから、含めなかったのかなmrsekut.icon

参考

https://youtu.be/yBcnonX8Eak?t=675